There are two starting points to approach this invention. On one hand, the increase in the number of mobile devices (and other multimedia devices having limited computing power) capable of playing back multimedia contents, and on the other hand, the already existing distributed computing network (known as GRIDs).
Focusing on the first point, new mobile devices (smartphones, PDAs, etc.) are increasingly designed with displays having greater resolution and better video playback performance.
However, there is a trend of recording very high resolution videos (even in high definition) or using compressed formats requiring a significant processing capacity in order to achieve a smooth playback and strongly limiting the video playback possibilities offered by current devices. For example, there are few mobile telephones which support the DivX codec, one of the most widespread on the Internet for video distribution. As a result, the content providers or the users themselves are forced to convert the content to enable playing it back on their terminals. To that end, there are several options, but generally some hardware and an application external to the terminal is needed such as:                The user can use a local DLNA server with direct access to the video file source for carrying out the conversion, while the DLNA client application which must be run in the terminal receives and plays back the content.        The content provider itself could be responsible for converting the original video for generating a converted copy suitable for the specific needs of the user terminal.        
In this line of creating copies of content, the provider or the user could use a web service exclusively intended for conversion provided by a third party. This third party could in turn use the infrastructures supplied by a cloud computing provider, such as Amazon EC2, for example, in order to perform costly video conversions. However, this option is more content provider orientated and, in any case, the original file must be sent to the third party, the converted video being recovered later on. This process consumes a large bandwidth and having this bandwidth is not always possible for the end users.
Changing the focus towards distributed computing networks, the GRID platforms have been mainly used for intensive computing tasks (complex scientific calculations for industrial simulations). However, until the arrival of cloud computing, there were not many commercial initiatives offering computing capacities for the end users from their own devices. Today there are products such as Amazon® EC2 or Google® App Engine which allow contracting a specific amount of remote computing power.
On the other hand, the XtreemOS project financed by the European Commission under the 6th Framework Programme allows easy and harmonious integration with the GRID platforms. In fact, one of the specific research lines of XtreemOS focuses on accessing the GRID platforms from mobile devices, offering the end users the capacities offered by GRID computing. The present invention thus focuses on exploiting the native capacities of GRID platforms from devices with a limited computing power in order to transcode video in the GRID, taking into account that those tasks related to video conversion (format, resolution, etc.) require high computing power not usually available on the user terminals such as mobile telephones, PDAs, etc.
Converting average or high quality videos using codecs such as DivX, Xvid or H.264 is a high consumption process in terms of processing, memory and storage space. Many devices with limited computing power (such as mobile telephones, PDAs, portable multimedia devices, etc.) are not intended for carrying out this conversion either because they do not have enough capacity or the time necessary for the conversion is too long, or even because the battery consumption would be excessive for such terminals. Given that the computing capacity of the equipment continues to grow year after year, it is difficult to quantify what is understood by limited computing capacity, but it can be considered that the computing capacity is limited when the equipment in question is capable of performing a number of instructions per second which is at least one order of magnitude below what a mid-range personal computer would be capable of performing. For example, currently a mid-range PC tends to be equipped with Core 2 Duo processors, with a performance of the order of tens of thousands of MIPS (millions of instructions per second). In turn, a current mobile terminal, such as the Nokia® N800 Tablet PC for example, is equipped with a processor from the ARM11 family with a processing capacity less than one thousand MIPS.
On the other hand, many of those devices are equipped with some type of data interface, such as Wi-Fi or 3G, and have relatively advanced operating systems installed. Furthermore, they incorporate some video play back applications and video codecs which are run directly in the terminal itself. The video source can be local or is downloaded and played back from an external source by means of streaming techniques. But in any case, the playback is only possible if the video is coded with one of the codecs supported by the terminal. If not, the video must be transcoded into a suitable format if the terminal has an application specifically designed to that end, but even in this case, carrying out the transcoding in the same terminal would not be advisable given the following situations:
i) the video source is not local,
ii) the user does not want to consume the limited resources of its terminal.
Other solutions based on Web services provided by third parties (such as the online video file conversion service, flixcloud, for example,) attempt the prior installation of the conversion application in the Web server and use a Web interface which will not always be the native interface of the operating system of the terminal, forcing the applications of the terminal to be modified. Modifying the application would be less complex or would not even be necessary with a solution based on middleware with GRID capacities.